Review the following considerations, limitations, and behavioral characteristics associated with OVSDB protocol support for VXLAN Gateway.
OVSDB protocol support for VXLAN Gateway requires at least one Network Virtualization Controller (NVC) that runs OVSDB:
OVS is an open source implementation of a virtual switch and OVSDB is a standard defined in RFC 7047.
You require at least one NVC. The NVC is an ESXi host server that runs the VMware NSX Network Virtualization and Security Platform (minimum version 6.2.4).
Note
VMware NSX 6.2.4 has known issues that can cause VXLAN discovery delays and NVC connectivity issues in certain scenarios, for more information see VOSS Release Notes.
You must configure VMware NSX. You can add a Hardware VTEP, add a logical switch, configure VNID to VTEP bindings, and configure a replication cluster in NSX.
The NSX logical switch on the NVC is assigned a VNID. The VXLAN Gateway is assigned an OVSDB managed interface I-SID. You must configure the VNID to I-SID binding in NSX.
SSL is the default protocol for NVC to VXLAN Gateway communications.
You can configure more than one NVC in a controller cluster for high availability and load-balancing.
The NVC performs MAC learning on the VXLAN tunnel.
ARP supression is not supported.
One NVC manages all encapsulated Broadcast, Unknown Unicast, and Multicast (BUM) traffic. This NVC replicates the BUM traffic to all other VTEPs in the network. If connectivity to the NVC managing BUM traffic fails, a loss of BUM traffic can occur. NVC cluster NSX service node replication is not applicable for BUM traffic.
The following diagram shows an example of NVCs managing a distributed virtual network.
The VXLAN Gateway must operate in Full Interworking mode.
You must configure at least one NVC connection to the VXLAN Gateway.
You can configure up to three NVCs connections to one VXLAN Gateway in this release.
The VXLAN Gateway must use the Segmented Management Instance IP address to connect with the NVCs. For more information about how to configure Segmented Management Instance, see Segmented Management.
You cannot change or delete the VTEP source IP address when OVSDB is enabled.
The OVSDB managed interface I-SIDs are communicated to the NVC as physical ports of the switch.
EDM support for OVSDB is limited in this release. You can use CLI where EDM configuration is unavailable.
The VXLAN Gateway general considerations and limitations also apply to OVSDB protocol support for VXLAN Gateway.
Note
NVC connectivity issues for SSL communication failures are not logged on the switch. You can use the logs on the NVC to troubleshoot SSL communications with the VXLAN Gateway.
OVSDB protocol support for VXLAN Gateway uses OVS modules on the VXLAN Gateway. The switch runs the following OVS modules:
OVSDB server — Manages the database.
Database — Manages the OVS schema and HW VTEP schema and JSON content.
Note
OVSDB replication is different than NSX service node replication. Service node replication is configured and supported in NSX. OVSDB replication uses vIST and is configured and supported on the VXLAN Gateway.
You require at least two NVCs to enable OVSDB replication.
OVSDB replication operates in an ACTIVE-STANDBY server configuration.
You must disable OVSDB on the standby vIST device before disabling OVSDB on the active vIST device.
One active NVC and one standby NVC are supported by the VXLAN Gateway.
VNID to I-SID binding, Remote VTEPs, VNI to Remote VTEPs for BUM, Remote MACs, and Local MACs are replicated across NVCs.